Field of the Invention
The present invention relates to methods for managing API call limits for a client in an authorization delegation system, and particularly relates to authority management servers and authority management methods regarding API calls from multiple clients in the same tenant.
Description of the Related Art
Recent years have seen an increase in the use of what are known as cloud-based services implemented over the Internet. It is becoming more and more common for businesses as well as individuals to manage customer relationships using a CRM (Customer Relationship Management) service, distribute and collect information in real time using an SNS (Social Networking Service), and so on, for example. Many of these cloud-based services publicize individual web service APIs, and it is now possible to use functions provided by such services from other applications, cloud-based services, and so on via the APIs. As a result, there is a continued increase in mashup functions in which multiple APIs publicized by multiple cloud-based services are combined in order to configure a service that operates as if it were a single web service.
However, the increase in opportunities to use mashup functions by which multiple cloud-based services cooperate has also given rise to several problems. For example, there is a risk that more information than a user intends to share will be exchanged among the multiple cloud-based services, heightening the risk of user data, personal information, and the like being leaked. It is generally preferable not to collect more user data, personal information, and so on than is required for each cloud-based service, and it is further necessary to prevent the user data, personal information, and so on from being provided to cloud-based services that the user does not wish to cooperate. Meanwhile, from the perspective of service providers, it is preferable to make it easier to realize a system for cooperation of cloud-based services. In light of such circumstances, a standard protocol for cooperation of authorizations, called OAuth 2.0, has been developed (see “The OAuth 2.0 Authorization Framework,” (online), D. Hardt, May 2013, retrieved from http://tools.ietf.org/html/rfc6749).
According to OAuth 2.0, when, for example, there is an API that acquires the data of a user managed by a service A, a service B that is authorized by that user can access the stated API. At this time, a range that will be accessed by the service B is made clear, whereupon the service A obtains explicit authorization from the user for the service B to access the API. The user carrying out this explicit authorization is referred to as an authorization operation.
When the user carries out the authorization operation, the service B receives a token authorizing access from the service A (called an “access token” hereinafter), and the service B can subsequently access the service A's API by using that access token. The process by which the user's authorization operation allows a service to access user resources managed by a different service is referred to as the delegation of authorizations. When the access token is used, the service B can access the service A's API under the authority of the user who made the authorization, without needing that user's credentials. As such, the service B that has been authorized by the user and that has obtained the access token has an obligation to manage the access token properly and with care.
According to OAuth 2.0, it is necessary for the service B to be authenticated in order to prevent spoofing of the service B. To authenticate the service B, it is necessary for the service A to issue the service B's credentials in advance, and specifically a client ID and a secret, manage the credentials, and furthermore set those credentials in the service B. Hereinafter, the service A that provides a resource will be referred to as a “resource server”, whereas from the perspective of the service A, the service B, or in other words, the other service that uses the resource server under the authority delegated by the user of that service, will be referred to as a “client” (of that resource server). According to OAuth 2.0, it is possible to separately configure an authorization server that carries out the aforementioned user authorization operations, the issuing of access tokens, and the authentication of clients, and a resource server that manages user data as resources and publicizes APIs as web services. In such a case, the service B accepts the delegation of authority from the user, obtains the access token from the authorization server, and uses that access token to access the API of the resource server. The resource server is configured to request the authorization server to verify the obtained access token, grant access to the resource only in the case where the access has been authorized, and then return data to the service B.
Typically, in a cloud-based service, an API publicized by a web service monitors a number of uses per unit of time for each client (see Japanese Patent Laid-Open No. 2007-328417, for example). This is done in order to prevent a drop in the overall quality of the service resulting from the API being used excessively by a specific client. In particular, paid services that charge based on the amount the service is used often provide limits on the number of times the service can be used in a unit of time and reject access after the limit has been reached. This is because a paid service is basically made usable under a contract with a user, and the operator of a paid service has an obligation to provide the service in a stable manner in accordance with the details of that contract. An SLA (Service Level Agreement) is known as an example of such a system for ensuring the quality of a service. An SLA defines such items as a minimum speed of the service being provided, a limit on the amount of time for which the service can be used, and so on. A user then pays a fee as compensation for the service quality defined in the SLA. The SLA also defines penalties for the service provider, user guarantees such as reductions in usage fees, and so on for cases where the promised quality is not provided. As such, with a paid service, it is extremely important for the quality defined in the SLA to be maintained, which means that it is important to prevent drops in the service quality by setting limits on API usage amounts and rejecting access when the limits have been reached.
The following configuration can be considered for a situation in which a company's internal system, namely multiple clients present in a tenant, cooperates with a cloud-based service. “Tenant” is a unit used to distinguish entities to which a resource is provided, and is a unit by which users use and manage the cloud. For example, in a case where multiple users utilize the same resource server, the information of the users managed by the resource server is divided into independent units, and these divided units correspond to “tenants”. In other words, a configuration can be considered in which each client functions as a tenant client for a specific tenant in the cloud-based service (that is, the resource server), and multiple clients can use multiple services through the specific tenant. In this configuration, a data upload client, a form client, and a print client for a cloud-based service to which a tenant belongs are provided in that tenant, for example. It is assumed that the API usage limit management is implemented as limit management through OAuth, on a tenant-by-tenant basis.
However, the aforementioned OAuth configuration, or in other words, a configuration including the authorization server that issues access tokens and the resource server that publicizes the API, has the following problem. When there is an API usage limit number in a specific tenant, and a client uses the API of the service A excessively and reaches the usage limit, the API of the service B can no longer be called. In other words, the number of times an API in a given service can be used is affected by the usage situation of an API in another service.